人物介紹請參考：人生就是在不斷的被拒絕後，找到希望(人物介紹)
前情提要：人生就是在不斷的被拒絕後，找到希望（1）

把想法分成兩篇，有一部分是因為當自己在回想事件的發生經過時，又發覺一些之前沒有注意到的想法，所以決定花一天來整理一下思緒。

當時討論需求後，其實我是有點灰心的，更正確的說法應該是信心受挫，原因是自己期許能跟開發團隊快速開發出維運團隊需要的功能，但在討論各種方案，卻都無法來得及滿足對方需求，還要讓維運工程師自己完成的暫時版的時候，信心滿受挫，但其實自己也知道，臨時版本跟完成版本的功能差異滿大的，也明白維運團隊日積月累的經驗，能夠自給自足（？）是正常的，所以心情一直是很複雜的。

心情有多複雜呢？

• 因為自己與團隊無法在時間內達成需求，所以感到有點氣餒，也有點喪失信心
• 維運工程師可以自己先開發暫時版頂著用，所以覺得有點開心、佩服，但有點討厭

事情後來怎麼發展呢？不管是跟主管還是維運團隊，我們都又聊了幾次合作方式與部門定位，達到的共識是『如果整體複雜度較高，但又略微急迫的』就由維運團隊自行開發臨時版本，而開發團隊就是負責把臨時版本更加完善，慢慢地構築一套涵蓋多種工具的維運系統。

這樣做還有什麼好處？一線的維運工程師自己設想的工具會是最實用的，沒有擔任過一線的處理人員，其實很難了解什麼樣的流程是最合適的！想像的樣貌也不一定準確，所以如果能夠先由使用者自己就先做出臨時版做出來，先讓一線同仁使用後，確任有滿足業務需要，再讓開發團隊根據臨時版，設計翻新成架構穩健的系統。『如果是有需要，但是又不造成一線人員立即性困擾的』，那就由開發團隊安排時程，逐步開發完成後再交付給維運團隊。

我覺得就滿像 DevOps 的循環，不過這樣說完一個經歷後，我覺得我們目前運作的方式像是有個開發團隊跟維運團隊相互配合的大循環，以及一個維運團隊內部的小循環（自行開發有一個臨時版工具，確認滿足需求後，再給開發團隊完善系統）。